Or any support people for that matter.  I constantly hear people having to support this, support that, wearing the “beeper”, etc etc.  But these people do seemingly love what they do, because I hear this on “non-essential” communications channels, like Twitter, SQL Saturday conversations, etc.  These are people who are doing what they do because they like it.

I have to be honest with you though, about the second time I was awakened by a beeper with the same problem I would be outraged. In fact I was, a long time ago. Luckily though, I worked for a company where I was the dba, programmer, and support for the database stuff. So when I had to do any support, I learned from the experience and fixed it so I wouldn’t have to do it again.

This topic is basically centered around why I had an extra 45 minute this morning to write a blog post when I actually should still be in bed.  I built an database transform/copy SSIS package that runs at 2:00 am. It is (for the time being) reliant on a database that gets restored by 1:00 am… only last night it was done at 2:15. The steps to drop constraints and truncate the table worked marvelously. The ones to reload… not so much…

This is a new process and is currently in working development state (it is more or less done, but the code that uses this data isn’t actually complete yet.  But still, my phone that delivers my corporate email buzzed before 8:00 am, and I noticed that it was an email from another developer asking “where is my data”. So I hit the computer and realized the bug… thankful it wasn’t something else.

Even this little disturbance to my lying in bed getting ready to get up pattern is enough to make me wonder how dbas do it. Buzz…process failed.  Buzz…process failed.  Email… why is my data not ready yet.  And they aren’t usually the one who created the mess.  Often it is the data programmer, or even just programmers that are good with C#, not so good with that easy to learn easy to work with, no brains necessary T-SQL (I am paraphrasing the thoughts of more than a few programmers).

What is the key to all of this… programmer (data and otherwise) care for the other person. When I was coding and supporting the databases, I learned to be mindful of a very good friend of mine, Future-Me. Future-Me is the recipient of everything I do. What I eat, what I do, and what kind of solutions I produce.  Future me also gets pretty perturb as Current me when he thinks back to all of the stupid things he has said.  Some people don’t even think about the future because they have no plans to stay in their current jobs.  Me, well, I might leave some day, but I plan to stay forever.  And a future of well built, well managed systems that always work sounds wonderful (unlikely in many ways, but wonderful.)

I have always said that every programmer should be forced to do the job of the persons they are writing software for, using the software they created. 40 clicks to do a task during development sounds marginally okay, but if you have to do that task 100 times a day, that is 4000 clicks! Sometimes this is referred to as dogfood testing, like having the people who develop dogfood taste their food (since dogs do like ‘em some table scraps!) Frankly I would rather be an actual dogfood tester than need to click the mouse 4000 times for one of my tasks (plus a few thousand for Solitaire and you are bound to start an epidemic at your company of Carpal Tunnel syndrome.)

I honestly should have considered the fact that the data might be delayed and implement something to protect against this. Either by timing, or by basically making the SSIS package check for the status/existence of the database.  You can bet that I will make sure that happens. And if I was a dba that kept getting errors that others created… well, I don’t want to say I would revolt, but I certainly wouldn’t just grin and bear it.

Hence the reason I talk so much about design. Good design begats good support patterns.  Bad design begats something altogether.